<!doctype html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title></title>
	<link rel="stylesheet" type="text/css" href="http://paranoid.net.cn/semantic.css" >
</head>
<body>
<section-title-en>2.8 Privilege Level Switching</section-title-en>
<section-title-ch>2.8 特权级别切换</section-title-ch>
<p-en>
	Any architecture that has software privilege levels must provide a method for less privileged software to invoke the services of more privileged software. For example, application software needs the OS kernel's assistance to perform network or disk I/O, as that requires access to privileged memory or to the I/O address space.
</p-en>
<p-ch>
	任何具有软件特权级别的架构都必须提供一种方法，使特权较低的软件能够调用特权较高的软件的服务。例如，应用软件需要操作系统内核的协助才能进行网络或磁盘I/O，因为这需要访问特权内存或I/O地址空间。
</p-ch>
<p-en>
	At the same time, less privileged software cannot be offered the ability to jump arbitrarily into more privileged code, as that would compromise the privileged software's ability to enforce security and isolation invariants. In our example, when an application wishes to write a file to the disk, the kernel must check if the application's user has access to that file. If the ring 3 code could perform an arbitrary jump in kernel space, it would be able to skip the access check.
</p-en>
<p-ch>
	同时，不能给权限较低的软件提供任意跳转到权限较高的代码中的能力，因为这将损害特权软件执行安全和隔离不变性的能力。在我们的例子中，当一个应用程序希望将一个文件写入磁盘时，内核必须检查应用程序的用户是否有访问该文件的权限。如果环3代码能够在内核空间中进行任意跳转，它就能够跳过访问检查。
</p-ch>
<p-en>
	For these reasons, the Intel architecture includes privilege-switching mechanisms used to transfer control from less privileged software to well-defined entry points in more privileged software. As suggested above, an architecture's privilege-switching mechanisms have deep implications for the security properties of its software. Furthermore, securely executing the software inside a protected container requires the same security considerations as privilege level switching.
</p-en>
<p-ch>
	基于这些原因，英特尔架构包括特权切换机制，用于将控制权从权限较低的软件转移到权限较高的软件中定义明确的入口点。如上所述，一个架构的特权切换机制对其软件的安全属性有深刻的影响。此外，在受保护的容器内安全地执行软件，需要考虑与特权级别切换相同的安全问题。
</p-ch>
<p-en>
	Due to historical factors, the Intel architecture has a vast number of execution modes, and an intimidating amount of transitions between them. We focus on the privilege level switching mechanisms used by modern 64-bit software, summarized in Figure 19.
</p-en>
<p-ch>
	由于历史因素，英特尔架构有大量的执行模式，它们之间的转换量也大得吓人。我们重点介绍一下现代64位软件所使用的特权级别切换机制，总结如图19。
</p-ch>
<img src="fig.19.jpg" />
<p-en>
	Figure 19: Modern privilege switching methods in the 64-bit Intel architecture.
</p-en>
<p-ch>
	图19：64位英特尔架构中的现代权限切换方法。
</p-ch>
<section-title-en>2.8.1 System Calls</section-title-en>
<section-title-ch>2.8.1 系统调用</section-title-ch>
<p-en>
	On modern processors, application software uses the SYSCALL instruction to invoke ring 0 code, and the kernel uses SYSRET to switch the privilege level back to ring 3. SYSCALL jumps into a predefined kernel location, which is specified by writing to a pair of architectural MSRs (§2.4).
</p-en>
<p-ch>
	在现代处理器上，应用软件使用SYSCALL指令调用0环代码，内核使用SYSRET将特权级别切换回3环。SYSCALL跳转到一个预定义的内核位置，这个位置是通过写入一对架构MSR（§2.4）来指定的。
</p-ch>
<p-en>
	All MSRs can only be read or written by ring 0 code. This is a crucial security property, because it entails that application software cannot modify SYSCALL's MSRs. If that was the case, a rogue application could abuse the SYSCALL instruction to execute arbitrary kernel code, potentially bypassing security checks.
</p-en>
<p-ch>
	所有的MSR只能由0环代码进行读写。这是一个至关重要的安全属性，因为它意味着应用软件不能修改SYSCALL的MSR。如果是这样的话，流氓应用程序就可以滥用SYSCALL指令来执行任意的内核代码，有可能绕过安全检查。
</p-ch>
<p-en>
	The SYSRET instruction switches the current privilege level from ring 0 back to ring 3, and jumps to the address in RCX, which is set by the SYSCALL instruction. The SYSCALL / SYSRET pair does not perform any memory access, so it out-performs the Intel architecture's previous privilege switching mechanisms, which saved state on a stack. The design can get away without referencing a stack because kernel calls are not recursive.
</p-en>
<p-ch>
	SYSRET指令将当前的特权级别从环0切换回环3，并跳转到RCX中的地址，该地址由SYSCALL指令设置。SYSCALL / SYSRET对不执行任何内存访问，所以它比英特尔架构以前的特权切换机制更胜一筹，以前的机制把状态保存在堆栈上。由于内核调用不是递归的，所以设计可以摆脱不引用堆栈。
</p-ch>
<section-title-en>2.8.2 Faults</section-title-en>
<section-title-ch>2.8.2 故障</section-title-ch>
<p-en>
	The processor also performs a switch from ring 3 to ring 0 when a hardware exception occurs while executing application code. Some exceptions indicate bugs in the application, whereas other exceptions require kernel action.
</p-en>
<p-ch>
	当执行应用程序代码时发生硬件异常时，处理器也会执行从环3到环0的切换。有些异常表示应用程序中的bug，而其他异常则需要内核操作。
</p-ch>
<p-en>
	A general protection fault (#GP) occurs when software attempts to perform a disallowed action, such as setting the CR3 register from ring 3.
</p-en>
<p-ch>
	当软件试图执行不允许的操作时，如从环3设置CR3寄存器，就会发生一般保护故障（#GP）。
</p-ch>
<p-en>
	A page fault (#PF) occurs when address translation encounters a page table entry whose P flag is 0, or when the memory inside a page is accessed in way that is inconsistent with the access bits in the page table entry. For example, when ring 3 software accesses the memory inside a page whose S bit is set, the result of the memory access is #PF.
</p-en>
<p-ch>
	当地址翻译遇到一个P标志为0的页表项，或者当页内存储器的访问方式与页表项的访问位不一致时，就会发生页故障（#PF）。例如，当环3软件访问S位被设置的页内存储器时，存储器访问的结果是#PF。
</p-ch>
<p-en>
	When a hardware exception occurs in application code, the CPU performs a ring switch, and calls the corresponding exception handler. For example, the #GP handler typically terminates the application's process, while the #PF handler reads the swapped out page back into RAM and resumes the application's execution.
</p-en>
<p-ch>
	当应用程序代码发生硬件异常时，CPU会进行环切换，并调用相应的异常处理程序。例如，#GP处理程序通常会终止应用程序的进程，而#PF处理程序则会将交换出来的页面读回RAM中，并恢复应用程序的执行。
</p-ch>
<p-en>
	The exception handlers are a part of the OS kernel, and their locations are specified in the first 32 entries of the Interrupt Descriptor Table (IDT), whose structure is shown in Table 3. The IDT's physical address is stored in the IDTR register, which can only be accessed by ring 0 code. Kernels protect the IDT memory using page tables, so that ring 3 software cannot access it.
</p-en>
<p-ch>
	异常处理程序是操作系统内核的一部分，它们的位置在中断描述表（IDT）的前32个条目中指定，其结构如表3所示。IDT的物理地址存储在IDTR寄存器中，只有环0代码才能访问。内核用页表保护IDT内存，所以环3软件不能访问它。
</p-ch>
<img src="table.3.jpg" />
<p-en>
	Table 3: The essential fields of an IDT entry in 64-bit mode. Each entry points to a hardware exception or interrupt handler.
</p-en>
<p-ch>
	表3：64位模式下IDT条目的基本字段。每个条目都指向一个硬件异常或中断处理程序。
</p-ch>
<p-en>
	Each IDT entry has a 3-bit index pointing into the Interrupt Stack Table (IST), which is an array of 8 stack pointers stored in the TSS described in §2.7.
</p-en>
<p-ch>
	每个IDT条目都有一个3位的索引，指向中断堆栈表(IST)，它是一个由8个堆栈指针组成的数组，存储在§2.7所述的TSS中。
</p-ch>
<p-en>
	When a hardware exception occurs, the execution state may be corrupted, and the current stack cannot be relied on. Therefore, the CPU first uses the handler's IDT entry to set up a known good stack. SS is loaded with a null descriptor, and RSP is set to the IST value to which the IDT entry points. After switching to a reliable stack, the CPU pushes the snapshot in Table 4 on the stack, then loads the IDT entry's values into the CS and RIP registers, which trigger the execution of the exception handler.
</p-en>
<p-ch>
	当硬件异常发生时，执行状态可能会被破坏，当前的堆栈不能被依赖。因此，CPU首先使用处理程序的IDT条目来建立一个已知的良好堆栈。SS被加载一个空描述符，RSP被设置为IDT条目指向的IST值。切换到可靠栈后，CPU在栈上推送表4中的快照，然后将IDT条目的值加载到CS和RIP寄存器中，触发异常处理程序的执行。
</p-ch>
<img src="table.4.jpg" />
<p-en>
	Table 4: The snapshot pushed on the handler's stack when a hardware exception occurs. IRET restores registers from this snapshot.
</p-en>
<p-ch>
	表4：当硬件异常发生时，处理程序的栈上推送的快照。IRET会从这个快照中恢复寄存器。
</p-ch>
<p-en>
	After the exception handler completes, it uses the IRET (interrupt return) instruction to load the registers from the on-stack snapshot and switch back to ring 3.
</p-en>
<p-ch>
	异常处理程序完成后，使用IRET(中断返回)指令从堆栈快照中加载寄存器，切换回环3。
</p-ch>
<p-en>
	The Intel architecture gives the fault handler complete control over the execution context of the software that incurred the fault. This privilege is necessary for handlers (e.g., #GP) that must perform context switches (§2.6) as a consequence of terminating a thread that encountered a bug. It follows that all fault handlers must be trusted to not leak or tamper with the information in an application's execution context.
</p-en>
<p-ch>
	英特尔架构赋予了故障处理程序对产生故障的软件的执行上下文的完全控制权。这种特权对于处理程序（例如，#GP）来说是必要的，这些处理程序必须执行上下文切换（§2.6），作为终止遇到错误的线程的结果。由此可见，所有的故障处理程序都必须被信任，不会泄露或篡改应用程序执行上下文中的信息。
</p-ch>
<section-title-en>2.8.3 VMX Privilege Level Switching</section-title-en>
<section-title-ch>2.8.3 VMX 特权级别切换</section-title-ch>
<p-en>
	Intel systems that take advantage of the hardware virtualization support to run multiple operating systems at the same time use a hypervisor that manages the VMs. The hypervisor creates a Virtual Machine Control Structure (VMCS) for each operating system instance that it wishes to run, and uses the VMENTER instruction to assign a logical processor to the VM.
</p-en>
<p-ch>
	利用硬件虚拟化支持同时运行多个操作系统的英特尔系统使用一个管理虚拟机的管理程序。管理程序为其希望运行的每个操作系统实例创建一个虚拟机控制结构（VMCS），并使用VMENTER指令为虚拟机分配一个逻辑处理器。
</p-ch>
<p-en>
	When a logical processor encounters a fault that must be handled by the hypervisor, the logical processor performs a VM exit. For example, if the address translation process encounters an EPT entry with the P flag set to 0, the CPU performs a VM exit, and the hypervisor has an opportunity to bring the page into RAM.
</p-en>
<p-ch>
	当逻辑处理器遇到必须由管理程序处理的故障时，逻辑处理器会执行VM退出。例如，如果地址转换进程遇到一个P标志设置为0的EPT条目，CPU就会执行VM退出，而管理程序有机会将该页带入RAM。
</p-ch>
<p-en>
	The VMCS shows a great application of the encapsulation principle [130], which is generally used in high-level software, to computer architecture. The Intel architecture specifies that each VMCS resides in DRAM and is 4 KB in size. However, the architecture does not specify the VMCS format, and instead requires the hypervisor to interact with the VMCS via CPU instructions such as VMREAD and VMWRITE.
</p-en>
<p-ch>
	VMCS显示了一般在高级软件中使用的封装原理[130]在计算机架构中的巨大应用。Intel架构规定每个VMCS驻留在DRAM中，大小为4 KB。但是，该架构并没有规定VMCS的格式，而是要求管理程序通过VMREAD和VMWRITE等CPU指令与VMCS进行交互。
</p-ch>
<p-en>
	This approach allows Intel to add VMX features that require VMCS format changes, without the burden of having to maintain backwards compatibility. This is no small feat, given that huge amounts of complexity in the Intel architecture were introduced due to compatibility requirements.
</p-en>
<p-ch>
	这种方法使得英特尔可以增加需要改变VMCS格式的VMX功能，而不必承担必须保持向后兼容的负担。考虑到英特尔架构中因兼容性要求而引入了大量的复杂性，这并不是一件小事。
</p-ch>


</body>
</html>	